Add BackendReader trait#986
Conversation
Makes sense. But is that not moot given this branch's commits will be squashed before merge? |
|
@sergerad FWIW I find helping reviewers navigate PRs faster is one of the most impactful accelerants to shipping overall. |
5b83c87 to
5731053
Compare
|
@huitseeker I have rebased now. Note this branch's commits have been squashed as I avoided manual merging / cherry-picking to perform the rebase. Hope that is OK. |
|
@sergerad quite fine! Note a good way to perform this sort of cleanup w/o deleting commit history is to do an rebase (possibly an interactive one to visually check the results) skipping the empty (metadata-only) commits: |
huitseeker
left a comment
There was a problem hiding this comment.
The main API design question is whether LargeSmtForest should expose a reader() method analogous to LargeSmt::reader(). Without it, callers that already hold a forest cannot obtain a read-only forest snapshot because the backend field is private.
Have added LargeSmtForest::reader() |
bobbinth
left a comment
There was a problem hiding this comment.
Looks good! Thank you! Not a super in-depth review, but I left a few minor comments inline.
| /// Methods may place additional constraints on which errors are used to signal certain failures. | ||
| /// Such failures should not lead to data corruption of any persistent data. | ||
| pub trait Backend | ||
| pub trait BackendReader |
There was a problem hiding this comment.
nit (feel free to ignore): Would ReadOnlyBackend be a better name?
There was a problem hiding this comment.
Maybe, but would need to update SmtStorageReader and SparseMerkleTreeReader also for consistency.
|
@sergerad Merged on a red CI status, fyi |
|
@huitseeker thanks for letting me know. Wasn't expecting automerge to go ahead on red. |
Context
In #967 we created reader traits used by rocks db structs including a new snapshot reader struct.
We need to do the same for the large forest SMT traits and PersistentBackend.
Changes